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Abstract: We focus in this paper on the problem of configuring and managing network security devices, such as Fire- 
walls, Virtual Private Network (VPN) tunnels, and Intrusion Detection Systems (IDSs). Our proposal is the 
following. First, we formally specify the security requirements of a given system by using an expressive access 
control model. As a result, we obtain an abstract security policy, which is free of ambiguities, redundancies 
or unnecessary details. Second, we deploy such an abstract policy through a set of automatic compilations 
into the security devices of the system. This proposed deployment process not only simplifies the security 
administrator's job, but also guarantees a resulting configuration free of anomalies and/or inconsistencies. 



1 INTRODUCTION 



Specifying, deploying and managing access control 
rules for a network architecture is one of the main 
tasks of a security administrator. These rules are usu- 
ally implemented by different security devices, such 
as firewalls, virtual private network (VPN) tunnels 
and intrusion detection systems (IDSs). The config- 
uration of these devices must be compatible with an 
established security policy. In order to ensure this 
compatibility in the case of a simple network architec- 
ture, the configuration of the security devices may be 
obtained directly by translating the security require- 
ments into packages of specific rules for each of these 
devices. When the architecture is more complex and 
involves several security devices, this procedure may 
lead to anomalies in the configuration of these devices 
and become an important source of errors exploited 
by potential attackers. 

These anomalies can be classified as follows. 
Firewall anomalies, also defined in the literature as 
intra- and inter-firewall anomalies Q, and that refer 
to those conflicts that might exist within the local set 
of rules of a given firewall {intra) or between the con- 
figuration rules of different firewalls that match the 
same traffic {inter); tunneling anomalies, which refer 
to those conflicts that might exist when both firewalls 
and VPN tunnels match the same traffic; and intrusion 
detection system anomalies, which refer to those con- 



flicts that might exist when both firewalls and IDSs 
match the same traffic. 

There actually exist several proposals that address 
the problem of managing security policies free of 
anomalies. In (8), for example, the authors propose 
a refinement mechanism based on a high level lan- 
guage and that performs an automatic firewall deploy- 
ment through a refinement. However, its approach is 
not fully satisfactory since it does not apply a com- 
plete separation between the abstract security pol- 
icy and the security device features and technology. 
The authors in lfl3ll propose a more complete pro- 
posal by using the Organization Based Access Con- 
trol (OrBAC) model HI as a high level policy lan- 
guage and an ulterior set of compilations that derive 
the OrBAC specifications into specific device config- 
urations. Unfortunately, only firewall management is 
addressed in such an approach. Other approaches, 
such as 13 HU |6), on the other hand, present audit 
solutions for the analysis of more complex security 
setups, where not only firewalls, but also VPN de- 
vices and IDSs, are in charge of the whole network's 
security. However, the main drawback of these audit 
approaches relies on their lack of knowledge about a 
global security policy, which is very helpful for main- 
tenance and troubleshooting tasks. 

In this paper, we extend the refinement approach 
presented in lfl3l . and propose a more complete re- 
finement process to derive not only firewall config- 



urations, but also VPN/IPSec (Internet Security Pro- 
tocol Suite) and scenario-based IDSs configurations. 
We propose a 2-steps process to (1) formally spec- 
ify the global set of security requirements by using 
an expressive access control model based on OrBAC; 
and (2) a set of ulterior compilations to automati- 
cally transform such an abstract security policy into 
the specific configuration of each security device de- 
ployed over the system (e.g., firewalls, VPN/IPSec 
tunnels and IDSs). This strategy not only simplifies 
the administrator's job, but also guarantees that the 
management of policies at both high and specific level 
is completely free of anomalies, i.e., ambiguities, re- 
dundancies or unnecessary details. 

The rest of this paper is structured as follows. 
Section |2] presents some related works. Sections [5] 
and |4] overview our strategy and introduce the main 
aspects of our expressive access control model. Sec- 
tion |5] presents our deployment algorithms. Finally, 
Section[6]closes the paper with some conclusions and 
work in progress not covered in this paper. 



2 RELATED WORK 

There exist in the literature several proposals to man- 
age and deploy access control policies on security de- 
vices free of anomalies. We overview in this section 
those works that we consider close to ours. 

A first approach presented in proposes a re- 
finement mechanism based on a high level language 
that allows administrators to perform automatic fire- 
wall deployments. It uses the concept of roles to de- 
fine network capabilities, and propose the use of an 
inheritance mechanism through a hierarchy of enti- 
ties to automatically generate permissions. However, 
this approach is not fully satisfactory since it does 
not apply a complete separation between the abstract 
security policy and the security device features and 
technology. More specifically, it does not fix clear 
semantics, and its concept of role becomes ambigu- 
ous. A similar refinement approach is also presented 
in lfl6ll . However, and although the authors claim that 
their work is based on the RBAC model lfl8l . it also 
presents a lack of semantics — it seems that they only 
keep from the RBAC model the concept of role. In- 
deed, the specification of network entities, roles, and 
permission assignments are not rigorous and does not 
seem to fit any reality. 

The authors in [2] present an intrusion detection 
approach to enforce a security policy. They propose 
the use of a "neutral language" to define a global pol- 
icy which is further deployed into a heterogeneous 



system. As their work is focused on a Linux pro- 
tection language, the rules that cannot be translated 
into file access rules are to be translated into IDS or 
firewall rules. However, although the distribution of 
the global policy into the system is done in a manual 
fashion on different hosts/nodes, there is no algorithm 
explaining the choice of these hosts/nodes that opti- 
mally respond to global security requirements. Al- 
though some verification processes try to guarantee 
anomaly-free policies, only local configurations are 
considered. Some drawbacks when managing those 
anomalies are moreover pointed out in [9] and no so- 
lution has been yet presented. Furthermore, no IPSec 
devices are taken into account. 

The work presented in lfl3ll successfully applies a 
set of refinement transformation to derive from an ab- 
stract security policy based on the OrBAC model [ 1 ] 
into the network's firewalls that might be enforced. 
However, the network administrator has to assist the 
deployment of the access control rules by indicat- 
ing which firewall implements a specific rule. For 
instance, concerning a given rule stating a certain 
traffic is allowed (e.g., the ftp service) between two 
hosts, the administrator has to indicate which firewalls 
should implement an accept rule to fulfill this require- 
ment. We extend in this paper this later approach by 
introducing new security devices (VPN/IPSec -based 
tunnels and IDSs), improving some of the previous 
limitations, and guaranteeing that neither VPN nor 
IDS anomalies may apply over resulting setup. 

Some other approaches propose to directly ana- 
lyze existing configurations in order to warn and fix 
inconsistencies. The work presented in lfT4l . for ex- 
ample, concerns the analysis of VPN overlapping tun- 
nels in order to detect tunneling anomalies. In their 
approach, if an access rule concerning a protected 
traffic between two points is implemented by config- 
uring more than one IPSec overlapping tunnels, the 
risk is that in some network zones the IP packets cir- 
culate without any protection. The authors in [fT4l 
present a discovery process to detect such situations 
and propose a high-level language to deal with VPN 
policies. However, a significant aspect is ignored in 
their approach: the whole security policy cannot be 
seen as two independent aspects — VPN tunnels and 
the firewall issues. They should not be separately 
modeled. Otherwise, there is a risk of conflicts at the 
end of their process. The use of a single access model, 
as our approach does, solves this limitation and allows 
us to deal with security aspects as a whole. 

In |Q3], a complete taxonomy of conflicts in se- 
curity policies is presented, and two main categories 
are proposed: (1) intra-policy anomalies, which re- 
fer to those conflicts that might exist within the local 



configuration of security devices; and (2) inter-policy 
anomalies, which refer to those conflicts that might 
exist between the configuration rules of different se- 
curity devices that match the same traffic. The authors 
in [7 1 propose, moreover, an audit mechanism in order 
to discover and warn about these anomalies. In 0|6), 
some existing limitations in lfT31 are pointed out, and 
an alternative set of anomalies and audit algorithms to 
deal with these anomalies are proposed. However, as 
noted in |5), the main drawback of these solutions re- 
lies on the lack of knowledge about the security policy 
as a whole — from a global point of view — which 
is very useful for maintenance and troubleshooting 
tasks. The managing of anomalies during our refine- 
ment process, not only guarantees equivalent results, 
but also keeps with such a knowledge. 

Support tools can also be used to assist adminis- 
trators in their task of configuring security devices. 
The Cisco Security Manager [fTTfl. for example, is de- 
signed to support the security policy deployment on 
a heterogeneous network involving a large diversity 
of cisco-based devices. However, we observe the fol- 
lowing problems when using such a tool. First, it does 
not offer a semantic model rich enough to express a 
global security policy. Although there is the possi- 
bility of defining variables, and thus defining access 
rules involving such variables, the administrator tasks 
are not much simplified. The administrator always 
needs a global view of the topology in order to cor- 
rectly specify each rule to network devices; there is no 
automatic discovery of security devices that optimally 
implement an access rule involving an IP source and 
a destination, as our approach does. Furthermore, the 
lack of a real top-down approach as ours (cf. Sec- 
tion 3.1) is partially replaced by other tools — e.g., 
conflict discovery tools that need the administrator's 
assistance and that unfortunately only guarantee con- 
flict resolution for local configurations. 



3 SECURITY POLICY 
EXPRESSION 

3.1 Downward Approach 

Let us start by showing in Figure Q] the strategy of 
our approach. The informal security requirements 
specified in current language (informal layer) are first 
translated into a high level language based on the 
OrBAC model [1|. Although this translation to the 
OrBAC-based policy expression can not be wholly 
automatic, the abstract concepts in the OrBAC model 
(cf. Section [3~2l facilitate this translation for an ad- 



ministrator. Based upon this abstract security pol- 
icy that is detached from any specific security device 
technology (e.g., NetFilter |fl9l ), we defined a set of 
deployment algorithms marked in Figure Q] These 
compilers are further detailed in Section 5. The first 
compilation is iterated every time a sub-organization 
(e.g., a firewall) is revealed (in Section 3.3 we will 
explain the element that determines these iterations). 
The result is a package of rules written in a generic ex- 
pression (multi-target) and not for a specific technol- 
ogy. The second compilation takes into account the 
specific technology and grammar (syntax & seman- 
tics) of the security devices. For example, different 
transformations have to be conceived when dealing 
with NetFilter, Netasq or Cisco PIX firewalls. 
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Figure 1: Downward approach. 



3.2 Security Policy Specification 

OrBAC is the access control model we used to express 
the abstract security policy Q]. This model involves 
two levels of abstraction: (1) an organizational level 
("role", "activity", "view" and "context" concepts); 
and (2) a concrete level ("subject", "action", "object") 
— that are entirely compatible with our downward 
approach. The OrBAC model uses first order logic 
to write access control rules in the form of permis- 
sions (Isjpermited), prohibitions (Is .prohibited) and 
obligations (Is .Obliged). For example, a permission 
is derived as follows: 

V org, V s, V o, V a, V r, V V, V a, V c 
pennissionforg, r, a, V, c) A 
empower(org, s, r) A useforg, o, V) A 
considerforg, a, a) A holdforg, s, a, o, c) 
— » Isjpermitted(s, a, o) 

If the organization org grants role r the permis- 
sion to perform activity a in view v in context c and 
if the role r is assigned to subject s (empower), the 



object o is used in v (use) and a is considered the ac- 
tion implementing activity a (consider), s is granted 
permission to perform a on o. Let us note that the 
new concepts introduced by OrBAC are the follow- 
ing: (1) Activity, regrouping actions having common 
properties; (2) View, several objects having the same 
properties on which the same rules are applied; and 
(3) Context, a concept defining the circumstances in 
which some security rules can be applied. 

OrBAC is based on the organization concept as- 
signed to each network entity that deals with a part 
of the security policy. If the (virtual) LAN the se- 
curity policy is designed for, constitutes an organiza- 
tion then a firewall, an IDS or an IPSec device be- 
come sub-organizations (organization hierarchy) of 
this LAN organization. Roles are assigned to sub- 
jects, i.e., active entities in the network (e.g., a host, a 
server, a firewall interface). A subject is assigned one 
or several roles and will therefore obtain certain per- 
missions. The notion of role facilitates the handling 
of subjects and permissions. Permissions are obtained 
for each of the subjects according to their role. The 
activities are an abstraction of the network services. 
For example, the action defined as "ALL_TCP" in- 
cludes all tcp network services; "WEB" refers to https 
(port 443) and http (port 80). 

A view regroups the objects. As we have seen, 
at the concrete level of the OrBAC model, the rules 
appear as Is_permitted(s, a, o) meaning that an en- 
tity/subject s has the permission to perform the action 
a on the object o. Hence, the object is either a net- 
work entity (e.g., a web server) identified by its IP 
address or an IP packet with a given data payload. 
The context allows the definition of specific security 
requirements directly at the OrBAC level. Some of 
the permissions occur in a "protected" context; this 
leads to the configuration of an IPSec tunnel. On the 
other hand, a scenario-based IDS alert is triggered in a 
"vulnerability" context associated with an attack with 
a known signature; a specific IP payload may also be 
specified as a part of the attack signature. 

Finally, OrBAC, as also RBAC does US), defines 
role hierarchies, and also views, activities and context 
hierarchies ifTTI . In the specialization/generalization 
hierarchy, permissions and prohibitions are inherited 
downward. These hierarchies facilitate the adminis- 
trator's task by attributing privileges and also simplify 
the formalization of the security policy. 

3.3 OrBAC Security Policy 

The authors in 02] describe an XML-based OrBAC 
security policy implementation. We chose to keep the 
same XML environment, but we slightly modified and 



proposed new XML data structures to handle the IDS 
and IPSec devices. The network architecture shown 
in Figure [2] will be used to explain our methodology. 
It illustrates a private network (the "Corp" network: 
111 .222.0.0/16) including even geographically differ- 
ent sites. 

Accordingly to the OrBAC model, the scheme de- 
scribing the high level policy includes an organiza- 
tion. It is composed of the following parts: (1) The or- 
ganization's name; (2) An element describing the or- 
ganization structure; (3) A set of rules (permissions); 
and, if necessary, (4) a reference to a higher level or- 
ganization (organization hierarchy). 

In the "structure" element, we distinguish the enti- 
ties relevant for the security policy (the subjects) that 
compose the network, the roles assigned to these enti- 
ties and finally, the network services. The entities can 
be "host", "subnet" or "addressjnterval" types. Also, 
the entities exclusion is used to simplify the structure 
representation. As an example, the Internet entity is 
defined as 0.0.0.0/0 excluding the corporate "Corp" 
network 111.222.0.0/16: 

<entity> 

<entityName>Net</entityName> 
<subNet> 

<addr>0.0.0.0</addr> 

<mask>0</mask> 
</subNet> 
<exclusionEntity> 

<entityName>Corp</entityName> 
</exclusionEntity> 
</entity> 

The roles are assigned to the entities ("entity- 
Name"). The specialization/generalization role hi- 
erarchy is used to simplify the OrBAC rule expres- 
sion. This hierarchy is indicated by an XML child 
element of the "role" element: "seniorRole". For 
instance, the role "R_FW" or "R_VPN" is inherited 
by all subjects having firewall functionalities (e.g., 
"FW_Extern", in Figure 2), respectively IPSec func- 
tionalities (e.g., "FWJntern"). In the following ex- 
ample, the role "R_DNS_srv" (DNS server) is as- 
signed to the entity/subject "DNS_server" that inher- 
its the role of a server - "R_Srv". Thus, an access rule 
implying the role "R_Srv" will automatically be prop- 
agated to DNS server and other servers: 

<role> 

<roleName>R_DNS_srv</roleName> 
<seniorRole> 

<roleName>R_Srv</roleName> 
</seniorRole> 

<entity Name >DNS .server </ entity Name > 
</role> 




Figure 2: Topology example. 



The permissions at the abstract level respect the 
data structure shown in Figure 3. This XML schema 
is compliant with the OrBAC specification. The role 
"roleName" performs the activity "serviceName" on 
the object "target" with the role "target/roleName". 
The "context" element is optional. If the security 
policy does not specify any particular conditions in 
which this permission is attributed to the role "role- 
Name", the context is "default". Otherwise, the secu- 
rity policy may announce a "protected" context or a 
"vulnerability" one. In the first case, an IPSec -based 
tunnel must be created according to the "child ele- 
ments" of the "protected" context: the type of the 
encryption algorithm (e.g., AES), the entities which 
have to negotiate the tunnel, a time interval during 
which the IPSec tunnel is enabled, etc. The sec- 
ond case will correspond to an IDS alert; a possible 
(XML) attribute of the "vulnerability" context ele- 
ment may be the CVE vulnerability code if known 
ifTTl . Moreover, a "content" child element of the 
"context" will contain a specific data pattern as part 
of an attack signature. 

An important element of the "permission" is the 
"securityRole". According to the OrBAC terminol- 
ogy, "securityRole" identifies a sub organization. A 
"securityRole" is also responsible for the activation 
of certain contexts, thus the activation of an access 
rule. It designates the role attributed to the security 
device(s) which implement(s) the corresponding ac- 
cess rules. For example, a rule stating that the access 
from the "Internet" to the DNS server is allowed will 
be implemented by the firewall "FW .Extern"; thus, 
the "securityRole" is the role "R_FW .Extern". Fur- 
thermore, a permission that bounds the role "RJntra" 
and the target "Internet" will be duplicated on both 
firewalls "FWJntern" and "FW .Extern". In this case, 
the "securityRole" regroups both "R_FW Jntern" and 
"R_FW .Extern". 



In the case of less complex network architectures, 
the "securityRole" is given by the network adminis- 
trator. Concerning more complex architectures (and 
a great number of access rules), this security role as- 
signment is difficult to elaborate and can lead to er- 
rors. That is why we propose some algorithms to au- 
tomatically designate the right "securityRole" under 
the following two hypothesis: 

(1) We consider that the formal policy at the OrBAC 
level is correcQ: the "structure" (cf. Figure [3J is 
well defined, without ambiguities (e.g., a firewall 
is not attributed the role of a server) and the ac- 
cess rules (cf. the "permissions" in Figure 3) are 
well specified (e.g., there is no OrBAC rule shad- 
owed by any other). However, we admit that cer- 
tain rules cannot be implemented because the ad- 
equate security device (with the appropriate func- 
tionalities) is missing. Our algorithms can detect 
this kind of mismatch when deploying the policy. 

(2) Inside the (virtual) network the security policy is 
designed for, the IP packets flow according to the 
shortest path principle (as a routing protocol guar- 
antees). The shortest path principle is used to 
identify the device(s) on which a given security 
rule must be deployed. However, notice that the 
shortest path is not always unique. For instance, 
in Figure 2, there are two possible shortest paths 
from site.ext to Srv_BD. In this case, our algo- 
rithms attempt to deploy the security rule on each 
candidate shortest path. 

To achieve this, the OrBAC structure shown in 
Figure [3] is parsed and relevant information about the 
network topology is collected. Practically we will ob- 
tain a graph and the shortest path principle will be 
applied to it. We describe the methodology in the fol- 
lowing section. 

1 We prove in [ 12] that such an assumption is feasible. 



Figure 3: OrBAC organization structure. 



4 MODELING THE TARGET 
ARCHITECTURE 

4.1 Modeling the Topology 

At the OrBAC level, the security officer identifies the 
relevant active entities (i.e., subjects) and roles as- 
signed to these entities with respect to the network 
topology and the security requirements. A role can 
be assigned to more than one entity (e.g., all firewalls 
have the firewall role "R_FW") and an entity can have 
more than one role (e.g., a firewall can have IPSec 
functionalities). The hierarchy of roles is defined 
too (e.g., a multi-server that has the DNS_server and 
Web .server roles inherits inevitably the server role - a 
less specialized role). An entity can be either a host, 
a subnet or an address interval type. 

As mentioned in Section [331 the entity exclusion 
is used to achieve a better structuring and manage- 
ment of the entities. The DMZ zone is considered to 
be the 111.222.1.0/24 subnet excluding the two in- 
terfaces of the adjacent firewalls "FW .Extern" and 
"FWJntern" (cf. Figure [2]). Multi-level exclusions 
may also exist. For example, the "CorpLessIntra" 
is the "Corporate" entity (111.222.0.0/16) which ex- 
cludes the "Site_ext" entity (111.222.5.0/16) and the 
"Intra" entity (111 .222.2.0/24) which in turn excludes 
the internal interface of the firewall "FWJntern". 
"CorpLessIntra" defines briefly all hosts unused by 
general corporate employees and managed by "Ad- 
min" zone (1 1 1.222.3.0/24 - the network administra- 
tion zone). 

Regarding complex network architectures, one of 
the most difficult tasks for a security officer is to indi- 
cate each of the security devices (i.e., "securityRole") 
which optimally implement the access rules. In our 
approach, the security officer does not need to give 
such an indication because our algorithms find the 
right set of "securityRole" for each "permission" if 



"securityRole" exists. For this purpose, the OrBAC 
"structure" is initially parsed and we construct a graph 
where every node is a zonfl In order to do so, the fol- 
lowing information is automatically extracted during 
the initial phase of our process: 

- The functionalities of each security devices. For 
example, in Figure 2, the firewall "FWJntern" has 
fw & VPN functionalities (firewall and IPSec ca- 
pabilities). 

- The set of neighbors of each zone (based on their 
IP addresses and mask^l). For example, after 
parsing the "structure" corresponding to Figure[3] 
the neighbors of the zone "FWJntern" are the "In- 
tra", "DMZ" and "Admin" zones. 

As a result of this first parsing phase, we obtain 
the following two outputs: 

(1) A list of security devices, 
Ss, defined as follows: Ss = 

Uj {device j , functionalities j , [U„ {neighbors ,■„}] } . 

(2) A list of zones, Zones, define as follows: Zones = 
Ui{zonei[neighborsii l }]}, and where neighbors-^ 
is the neighbor k zones of the ;th zone. 

4.2 Modeling Paths 

Let us consider a rule at the OrBAC level; it implies a 
role ("roleName") and an object ("target/roleName") 
that corresponds to respectively a source "Src" and 
a destination "Dest" entities. This information is 
mandatory at the OrBAC level (cf. Figure 3). As al- 
ready mentioned, we developed an algorithm that out- 
puts the optimal set of "securityRole" based on the 
following three assumptions: 

2 A zone is either a subnet with no security device inter- 
facing any other subnet or the set of interfaces of a security 
device 

3 The establishing neighbors algorithm is based on the 
longest prefix matching scheme. 



- source_zone: U j {zone j} = S red Zones; 

- dest_zone: U,{zo«e,} = Dest HZones; 

- shortest_path : Zones x Zones — ► Ss, such that 
shortestjpalh(zone j,zonei)^-Uk { device^ } . 

Once identified the source and the destination 
zones for an access rule, the shortest paths between a 
source zone and a destination zone are computed and 
the security devices on this path are revealed. Some of 
these security devices will be designated as "security- 
Role". Moreover, the security devices on the shortest 
path must have the functionalities: 

- if the access rule is in a "default" context then fire- 
wall functionalities are necessary; 

- if the access rule is in a "protected" context then 
IPSec functionalities are required; 

- if the access rule is in a "vulnerability" context, 
then IDS functionalities are required. 

In a "default" context, a permission rule will be imple- 
mented on all firewalls found on the path; a prohibi- 
tion rule might simply be implemented on the security 
device which is the closest to the IP flow source (our 
shortest .path algorithm was designed so as to choose 
the most up-stream — the closest to the source — or 
the most down-stream — the closest to the destination 
— security device). The fact that an access rule is ei- 
ther a permission or a prohibition filtering rule is not 
relevant for our discussion. That is why for didactical 
reasons, we considered only permission rules in the 
"default" context. 



The compilation process is schematized in Fig- 
ure [4] The input is the OrBAC security policy; the 
intermediary results are represented by dotted lines. 
The final compilation result is a set of files consisting 
of the part of the security policy assigned to each "se- 
curityRole" (the "multi-target" level), "call" stands 
for function callings; "input" means that the interme- 
diary results serve as input for other processes. 
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Figure 4: First compilation phases. 

Concerning the first compilation, the main algo- 
rithms are the "SecurityRoleDiscovery", "exclusion 
entities treatment" and "IDS - Firewall_Redundancy". 
From the "multi-target" level, a second compilation is 
applied to obtain the packages of concrete rules ac- 
cording to the specific syntax of each relevant device. 

5.1 The SecurityRoleDiscovery 
Algorithm 



5 DEPLOYMENT ALGORITHMS 

The main part of the security policy deployment is 
included in the first compilation phase (cf . Figure [TJ 
as a set of four processes: 

- The "structure .parsing" with the main results, i.e., 
the list of security devices sf] and Zones; 

- the "hierarchies_treatement" including the role hi- 
erarchy treatment and the exclusion entities treat- 
ment; 

- the "securityRole" phase including the shortest 
path computation; 

- "multi-target" extracts all relevant information 
about the set of access rules the "securityRole" 
must implement, in a generic format. 



4 We recall, from Section 14.11 that Ss is 
the list of security devices, such that Ss = 
U j {device j , functionalities j , [U„ {neighbors j n }] }. 



The "securityRole discovery" takes into account, 
as an input, the "structure" (cf. Figure [3j> pars- 
ing results: Ss and Zones. It also uses the short- 
est jpath function. Let us assume the "permissions" 
= U, { permissioni } at the OrBAC level: 

Algorithm 1: SecurityRoleDiscovery 
l foreach permission-);, do 

call hierarchies_treatement; 
Ui{zoneSi} «- {Src n Zones); 
Uj{zoneDj} <- (Dest n Zones); 
foreach zoneS, do 
foreach zoneDj do 

if permission [context] — default then 

S s _iist *— shortest_path (zoneSi, zoneDj); 
if S s jisi [functionalities] = /<; then 
I securityRole <— S 3 jist', 
break; 



if permission ^[context] = protected then 

SrcJVPN list <— f ind_VPN_components_in Uk{zo'. 
Dest_VPN list — f ind_VPN_components_in Uk{z 
if shortest_path (zoneS I} zoneDj) 
passing_by (Src.VPN list.Dest.VPN list) then 

| call conf igure_VPN_IPsec_tunnel; 
else 

I warning ("V PN lunneljmpossible"); 
break 

if permissionk[context] = vulnerability then 
|_ call IDS-Fi rewall .Redundancy; 



v.Si[it.etyh.bors,i;]; 
neDj[neighbors jk \. 



A "permission" rale in a "default" context is im- 
plemented by all security devices with firewall func- 
tionalities on the shortest path. For example, given 
the topology in Figure[2] both firewalls "FW_site_Ext" 
and "FW .Extern" implement an access rule stating 
that "ftp" is allowed from the "site_ext" zone to the 
"DMZ" zone. 

In the "protected" context, we formulated an ex- 
tension to the shortest path function - passing J>y(): 

- it identifies the security devices - neighbors of the 
source and the destination zones having IPSec func- 
tionalities and it is supposed to compute a path be- 
tween two of them; 

- if a path exists, the algorithm finds the right in- 
terfaces negotiating the IPSec tunnel (longest prefix 
matching scheme); 

- new filtering access rules are to be implemented on 
the firewalls discovered on the tunnel path (for exam- 
ple, to enable the IPSec tunnel negotiation - isakmp 
with the above interfaces). This way, we avoid the 
conflict firewall <-» IPSec tunnel. 

Given the same topology (cf. Figure 2), let us 
consider an access rule stating that all TCP traffic 
from the zone "Intra" to the "site_BD" zone must 
be secured: Is-permited(RJntra, ALLJTCP, target- 
RsiteJSD, context-protected). With the previous al- 
gorithm, the "protected" context leads to the con- 
figuration of an IPSec -based tunnel. The IPSec 
tunnel will be implemented by "FWJntern" and 
"FW_BD_1" security devices because: (1) a path ex- 
ists from the "Intra" zone to the "site_BD" zone and 
(2) the path crosses these two security devices with 
IPSec functionalities in the immediate neighborhood 
of respectively the source IP traffic zone ("Intra") and 
the destination ("site_BD") zone. The interfaces in 
charge of the IPSec tunnel negotiation {isakmp) are 
the "FWJntern" interface adjacent to the DMZ zone 
and respectively the "FW_BD_1" interface adjacent to 
the Internet zone. A filtering rule permitting the corre- 
sponding isakmp traffic is automatically deduced and 
finally implemented in all firewalls on the tunnel path 
("FWJntern", "FW_Extern" and also "FWJJDJ"). 

If the access rule is in a "vulnerability" context, 
IDS-FirewallJiedundancy is called (cf. Section |53I >. 
Instead of deploying an IDS rule, we chose to exploit 
an eventual IDS-firewall redundancy. We do not con- 
sider any IDS-IPSec tunnel interaction because IDS 
generally works on an unencrypted IP traffic. 

5.2 The exclusion entities treatment 
Algorithm 

During the first compilation, we treat the hierar- 
chies of roles and activities (network services). Con- 



sequently, a permission involving the firewall role 
"RJ'W" will engage all entities/subjects playing a 
"RJ'W" role. These entities may contain other en- 
tities which are excluded. Deploying an access rule 
implying subjects/entities which exclude other enti- 
ties is solved as follows: 

- a permission at the OrBAC level involving entity 
El, El excluding E2 will be translated in a generic 
rule which will include El, El excluding E2; 

- a permission involving El, El excluding E2, E2 
excluding E3 will be translated in two generic 
rules: the first will involve El, El excluding E2 
and the second will involve E3; 

- a permission involving El, El excluding E2, E2 
excluding E3, E3 excluding E4, will be translated 
in two generic rules: the first will include El, El 
excluding E2 and the second will include E3, E3 
excluding E4; 

- a permission involving El, El excluding E2 and 
E3, E3 excluding E4 and E5, E5 excluding E6 will 
be translated in three generic rules: the first will 
include El, El excluding E2 and E3, the second 
will include E4 and the third will include E5, E5 
excluding E6. 

This reasoning derives from a simple mathemati- 
cal logic; for the last example, the entity El is defined 
as follows: 

£1 A(£2V£3) A£4V(£5A£6) = 

= {El A£2 V£3) V£4 V (£5 A£6) 

where "V" stands for the addition of a new 
generic permission at the multi target level (cf. Fig- 
ure|4]i; and "A" denotes an exclusion. 

5.3 The IDS-FirewallMedundancy 
Algorithm 

An access rule in the "vulnerability" context is de- 
ployed on a single IDS device on the shortest path 
binding the source and the destination of an IP flow. 
We chose the most down-stream IDS because it 
is more efficient against spoofing attacks than the 
most up-stream IDS. Moreover, we do not elim- 
inate the IDS-firewall redundancy: IDS alert sets 
off for IP packets that should have been blocked 
by an up-stream firewall. We take advantage of 
this redundancy in order to obtain relevant infor- 
mation regarding a malfunctioning firewall. The 
"IDS-FirewallJledundancy" algorithm is based on 
the shortest path principle with some extensions. To 
illustrate our approach, let us consider the topology 
shown in Figure [2] 



A rule in the "vulnerability" context for an IP flow 
with the "Intra" source zone and the "BD" destina- 
tion zone will be implemented by IDS_A. An analysis 
of the firewall configurations located on the shortest 
path connecting the "Intra" source and the "BD" des- 
tination is launched. We choose to "analyze" only 
the firewalls located up-stream; IDS_A cannot give 
any information regarding its malfunctioning down- 
stream firewalls. 

Let us consider that the up-stream fire- 
walls ("FW_BD_1", "FW_BD_2", "FW_Extern", 
"FW Jntern") apply a default deny all filtering policy. 
In this case, with our security policy deployment, 
they implement only permission rules {accept or 
pass). Each rule generally involves an IP source and 
destination address and a network service {ports). 
Let (S,D,P) be the triplet including this information. 
The entire policy of a firewall (e.g., "FW Jntern") 
may be resumed as follows: (1) pass" for F = (Si 
A Di A Pi) V (S 2 A D 2 A P 2 ) V ... V (S„ A D„ 
A P„), where n = the filtering rules number; (2) 
"deny" for non(F); (3) F and non(F) are included in 
the "3D" space [source, destination, service] where 
{source, destination) S [0.0.0.0 ; 255.255.255.255] 
and service G [0 ; 65536]. 

We refer to the IDS-firewall redundancy only if 
the set of parameters forming the firewall and the 
IDS rules are the same; thus, the (S,D,P) triplet 
is taken into account alongside the IDS "alert" 
rules and the firewall "deny" rule. For example, 
there is an IDS-firewall redundancy if an IDS alerts 
for the IP packets including W = (111.222.2.0/24, 
111.222.4.10, alLtcp) (regardless of their payload) 
and an up-stream firewall performs deny for the 
(111.222.2.32/27, 111.222.4.10, alLtcp) triplet. Our 
"IDS-Firewall_Redundancy" algorithm finds the in- 
tersection between each triplet W (corresponding to 
an alert) and non(/ 7 ;) for each up-stream firewall FWi. 

Algorithm 2: IDS_Firewall_Redundancy 



// Let IDSn be the most down-strea 

/ / softest jnath(souree, destination) . 

II 



IDS of the 



of the 

ed just before IDSn. 



II Let FW N be the last firewall 
/ / sortesi-pathisource, destination) pla 
// 

1 foreach FWi € shortest-path (sov,rce,destination) do 

2 if existsf/DS^eE shortest jpath (source, destination) then 
W r «- W n non(F,); 
W a ^W- W,.; 
if Wr + then 

alert_with_Wr_in (IDSi) k "malfunction FWi"; 
W ^W a ; 



else if IDSi = IDSn then 
W r «- W nnon(F N ); 
W a ^W - W,.\ 
if W r /0then 

I alert_with_Wr_in {IDSn) & "malfunction FWtf"; 
alert_with_Wa_in (IDSn); 
break; 



Since Wr = W n non(Fi) and Wa = W-Wr, then: 

- A first IDS rule will be implemented in the imme- 
diately down-stream IDSj against the firewall FWi 
the previous intersection was computed for. The 
IDS alert message will not only be the message 
corresponding to the attack but will also include 
"beware, malfunctioning FW". For example, in 
the case of IDS_A^V'FW Jntern" redundancy, in- 
volving Wr = W n non(F), an IDS rule involving 
Wr will be implemented in IDS Ji and thus the 
"FW Jntern" malfunction can be detected. 

- The last IDS rule will be implemented in the most 
down-stream IDS and include Wa. For the previ- 
ous example, an IDS rule with Wa and the unmod- 
ified message corresponding to the initial vulner- 
ability will be implemented in IDS_A. 



5.4 Final phase 



The second compilation phase (cf. Figure 1) trans- 
lates the generic rules to a specific security device 
technology. We deal with a library of transformations. 
Each transformation is conditioned by the security de- 
vice features. 

The intrinsic matching rule {first-matching, or 
last-matching) and the rule order are taken into ac- 
count when designing a transformation for a firewall. 
Let us consider that an entity excludes another en- 
tity in one generic permission; we have the choice 
to design either a transformation that outputs two 
rules (one of them being the negative rule and corre- 
sponding to the excluded entity) or a transformation in 
which the excluded entity is actually left out (the re- 
sult is a single pass/accept rule). In the first case, the 
negative rule must be placed before (first-matching) 
or after (last-matching) the positive rule. 

NetFilter offers a mean to skip the rule order im- 
portance. The authors in lfT3l use the jump and new 
chain functionalities each time exclusion entities are 
involved. However, not all firewalls we dealt with had 
these functionalities. The order of rules will not be 
important if we succeed in writing pass rules and only 
the last rule is deny all. We designed such a trans- 
formation in XSLT language for Netasq F200 IPS. 
On the other hand, and in order to obtain the IPSec- 
based tunnel configurations, another transformation is 
required. Therefore, we conceived one for the Ne- 
tasq F200 family which also includes the IPSec func- 
tionalities. As scenario-based IDS, we worked with 
SNORT-based IDS, for which we considered only the 
alert IDS rules and a specific transformation. 



5.5 Performance evaluation 

The complete set of algorithms and processes 
overviewed in this section have been implemented 
and evaluated in a first software prototype. Let us 
briefly present in this section some of the results we 
obtained. The implementation has been done by us- 
ing PHP, a general-purpose scripting language that is 
especially suited for web services development. In 
this way, the complete refinement process can be lo- 
cally or remotely executed by using a HTTP server 
(e.g., Apache server over UNIX or Windows setups) 
and a web browser. On the other hand, the evaluation 
was carried out on an Intel-Pentium M 1 .4 GHz pro- 
cessor with 512 MB RAM, running Ubuntu 6.0.6 with 
GNU/Linux 2.6. 15 (32 bits), and using Apache/2.0.55 
with PHP/5.1.2 interpreter configured. 

For our evaluations, we specified three different 
IPv4 simulated networks. The topology for the first 
network consisted of four subnetworks, one SNORT- 
based IDS and two firewalls the access rules were 
deployed on. The topology for the second network 
included five subnetworks, one SNORT-based IDS, 
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(a) Memory space evaluation. 
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(b) Processing time evaluation. 
Figure 5: Memory and processing time evaluations. 



three firewalls - two of them having IPSec capabil- 
ities. The topology for the third network consisted 
of six subnetworks, two SNORT-based IDS, five fire- 
walls - three of them with IPSec capabilities. For each 
topology we considered several security policies with 
an incremental number of OrBAC rules. 

During the evaluation, we measured the memory 
space and the processing time needed to perform the 
whole refinement process. The results of these mea- 
surements are plotted in Figur e |5(a)| and Figure |5(b)| 
We can first notice in Figure |5(a)| that an important 
part of memory consumption is due to the structure 
parsing phase (cf. Section |47TT > and then the memory 
increases linearly with the OrBAC rules number. On 
the other hand, we notice in Figure [5(b)] that the pro- 
cessing time is not due to the parsing structure phase 
but to the OrBAC rules number and complexity. 

However, although both memory space and pro- 
cessing time results are pointing out to strong require- 
ments, we consider they are reasonable since: (1) the 
implementation of our approach has been done by us- 
ing a high level scripting language, and we expect that 
the use of a more efficient language will clearly im- 
prove these results; (2) our approach relies on an off- 
line process which does not affect the performance of 
the security policy enforcement. 

We want finally to note that the implementation of 
our proposal in a software prototype demonstrates the 
practicability of our work; and the obtained results 
allow us to be very optimistic about its use in more 
complex security policy scenarios. 



6 CONCLUSIONS 

The configuration of security devices is a complex 
and cumbersome task. A wrong configuration of 
those devices may lead to weak security polices - eas- 
ily to be bypassed by unauthorized parties. In order to 
help security administrators, we have presented in this 
paper a refinement mechanism to properly configure 
and manage the following security devices: firewalls, 
VPN/IPSec-based tunnels, and scenario-based Intru- 
sion Detection Systems (IDSs). 

Our proposal allows the administrator to formally 
specify security requirements by using an expressive 
access control model based on OrBAC JT). As a re- 
sult, an abstract security policy, which is free of am- 
biguities, redundancies or unnecessary details, is au- 
tomatically transformed into specific security devices 
configurations. This strategy not only simplifies the 
security administrator's job, but also guarantees that 
the resulting configuration is free of anomalies and/or 
inconsistencies. The complete set of algorithms and 



processes presented in this paper have been imple- 
mented in a first software prototype, and the results of 
a first evaluation have been overviewed. Such imple- 
mentation demonstrates the practicability of our work 
and its performance results allow us to be very opti- 
mistic about its use in more complex security policy 
scenarios. 

As work in progress, we are actually studying how 
to extend our approach in the case where the security 
architecture includes IPv6 devices. More specifically, 
the construction of new VPN tunnels (e.g., IPv6-over- 
IPv4) for IPv6 networks must be revised, and more 
investigation has to be done in order to extend the 
approach presented in this paper. In parallel to this 
work, we are also extending our approach to make 
cooperate routing and tunneling policies. 
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